我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。

如果AI 流量突然增加，GPU 不夠了怎麼辦？

Day 20 我談到，當 AI Service 從「自己跑」變成「很多人使用」後，Kubernetes 可以協助管理大量 Container。

但接著又出現一個很現實的問題：

如果今天只有 10 個人使用，明天突然變成 1,000 個人，該怎麼辦？

一開始我直覺想到的答案是：「流量變大，就增加更多 Pod。」

但實際開始理解 Kubernetes 與 AI Inference 後，我發現真正困難的不是「增加 Pod」，而是到底什麼時候該增加？增加多少？什麼時候又可以縮回去？

Kubernetes 的 Horizontal Pod Autoscaler（HPA）可以根據觀察到的 Metrics，自動增加或減少 Deployment 的 Pod 數量。

但 AI Inference 又比一般 Web Application 更特殊。

如果只是看 CPU 使用率，可能根本看不出 GPU LLM Service 已經開始塞車。Google Cloud 目前針對 GKE 上的 GPU LLM inference，也建議考慮 Queue Size、Batch Size、KV Cache 使用率與 Latency 等更貼近模型服務的指標。Google Cloud 最新的 GKE inference 文件現在甚至提供以 NTPOT / TTFT latency 作為 HPA scaling threshold 的方式，代表 AI inference 的 Scaling 已經不只是傳統 CPU/Memory Autoscaling。

這讓我開始理解：

AI Autoscaling 不是單純「CPU 超過 80% 就加機器」，而是要知道模型服務真正的瓶頸在哪裡。

所以問題來了：

如果 GPU 已經接近滿載，但 CPU 看起來還很正常，AI Service 到底應該依據什麼指標決定要不要擴容？ 到底要什麼時候擴容？

這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》中，我希望從 Kubernetes、GPU 與 AI Inference 的角度一起思考的問題。Google Cloud 目前針對 GPU LLM inference 特別建議使用 queue size、batch size、KV cache、latency 等更貼近 inference workload 的指標；單看 CPU 可能導致效能與成本都不理想。一般 Web Application 的 Scaling 思維，不能直接套用到 GPU LLM Service。這也是AI Demo 為什麼上不了 Production？

關於作者

我是一名 AI × Infrastructure Solution / Integration 技術實作者，專注於 AI、MLOps、Cloud、Docker、Kubernetes、GPU、LLM 與 AI Agent 等技術的整合與落地，跨足 LLM、GPU、Docker、Kubernetes、MLOps 與 AI Agents，持續研究企業 AI 從 Prototype 到 Production 所需要的工程能力。協助企業理解 AI 從 Prototype 到 Production 所需要的技術能力。

本系列同時是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》的延伸實戰筆記。如果想完整理解這些更深的技術問題，未來可以去看這本書(書中包含了一些的範例與提示詞，特別是AMD W7900 48G的使用技術心得，這些是外面很少有的獨家踩坑經驗，未來買書真的賺到！)。敬請期待唷~ 關於永久網站也有了，正在準備了，很高興今天找到了設計師~